Skip to content

Conversation

@frederick-vs-ja
Copy link
Contributor

@frederick-vs-ja frederick-vs-ja commented Apr 24, 2025

...except for [tab:meta.trans.cv], because the wording change for add_cv seems a bit non-trivial, and for the return type of as_const, because the the change would affect mangled name.

Fixes #7845.

@eisenwave
Copy link
Member

There may be additional uses of std::add_lvalue_reference or std::add_pointer which aren't needed, but that's probably best done in a different PR. It's also less obvious whether the uses of those traits are pointless because they have some special behavior.

@jensmaurer
Copy link
Member

There may be additional uses of std::add_lvalue_reference or std::add_pointer...

Those should not be in this pull request.

@frederick-vs-ja
Copy link
Contributor Author

frederick-vs-ja commented Apr 24, 2025

There may be additional uses of std::add_lvalue_reference or std::add_pointer which aren't needed, but that's probably best done in a different PR. It's also less obvious whether the uses of those traits are pointless because they have some special behavior.

I believe that LWG4144 made uses of add_lvalue_reference_t pointless for unique_ptr. (Edit: This seems to be wrong, per this demo.) For the example in [exec.util.cmplsig.trans]/2, I think the use of add_lvalue_reference_t is also pointless, although add_lvalue_reference_t seems able to trigger more "accept-invalid" compiler bugs.

Other uses of add_lvalue_reference_t are meaningful since they handle std::common_with<void, void>.

For add_pointer_t, most uses are meaningful because they remove references. Its uses in std::get_if overloads are possibly meaningful but squirrelly when invalid variant specializations are involved (Godbolt link). Perhaps an LWG issue is necessary for this.

// \ref{utility.as.const}, \tcode{as_const}
template<class T>
constexpr add_const_t<T>& as_const(T& t) noexcept;
constexpr const T& as_const(T& t) noexcept;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This changes the mangled name for std::as_const specializations, but I don't think we need to care about that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a normative change though, so not editorial.

Copy link
Member

@jensmaurer jensmaurer Apr 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood; @frederick-vs-ja , please remove this change from the present editorial pull request and (at your option) create an LWG issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverted.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jensmaurer PTAL?

@jensmaurer jensmaurer added the changes requested Changes to the wording or approach have been requested and not yet applied. label Apr 24, 2025
@tkoeppe tkoeppe requested a review from jensmaurer July 17, 2025 13:05
@tkoeppe tkoeppe removed the changes requested Changes to the wording or approach have been requested and not yet applied. label Jul 17, 2025
...except for [tab:meta.trans.cv], because the wording change for
`add_cv` seems a bit non-trivial, and for the return type of `as_const`,
because the the change would affect mangled name.
@tkoeppe tkoeppe merged commit ebd315d into cplusplus:main Nov 21, 2025
2 checks passed
@frederick-vs-ja frederick-vs-ja deleted the lib-plain-cvqual branch November 22, 2025 01:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

add_const_t VS plain const

5 participants